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ABSTRACT 



An integrated three-tier application framework with auto- 
mated class and database table generation. Schema infor- 
mation in the form of metadata structures is used to generate 
data classes for the client tier and the application tier. 
Corresponding client tier and application tier data classes 
implement a common interface that supports generalized 
access by other system components. Based on the schema 
information, factory classes are automatically generated for 
the client tier and application tier which permit instantiation 
of the generated data classes. Also, database configuration is 
automated by the generation of database table creation 
commands from the schema information. In one 
embodiment, a framework of management components are 
provided for both the client and application tiers to handle 
inter- tier communication, transparent caching of data 
objects in a public store, handling of changes to data via 
change objects, handling of updates in response to data 
changes, and resolution of query objects into database 
queries. Common methods are generated within each data 
class which recognize the use of a public store and the 
application of a change object scheme. Further, methods and 
attributes are inherited from framework superclasses that 
identify and interface with a pubhc store, and that confer the 
concept of identity on a data class, as well as the ability to 
discover the attributes of the data class. 

7 Claims, 12 Drawing Sheets 
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MetaSchema 

String mySchema Version; 

Vector myCoreClasses; / / MetaClass 

FactoryClass myFactoryClass; 



500 



MetaClass 

MetaSchema mySchema; 

String myClassName; 

MetaClass mySuperClass; 

String myClassVersion; 

String myChangeObject; 

Vector myAttributes; / / MetaAttribute 

Vector myMethods: // MetaMethod 

Vector myPassedMethods; / / MetaMethod 

Vector mylmports; / / String 

Vector myCode; / / String 

Vector mylnterfaceCode; / / String 

boolean myAbstractFlag; 

boolean myPersistentPlag; 

boolean mylnterfaceFlag; 



501 



MetaMember 

int myPrivateFlag; 
MetaDataType myDataType; 
String myName; 
MetaClass myOwningClass; 
Vector myComments; / /String 
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MetaAttribute 

boolean myPersistentPlag; 
boolean myNullFlag; 
boolean myPrimaryKeyFlag; 
boolean myOfferNewMethodPlag; 
boolean mylndexFlag; 
String myDefaultValue; 
String myMirrorCollectionClassName; 
MetaClass myMirrorCoilectionClass; 
String myMirrorAttributeName; 
MetaAttribute myMirrorAttribute; 
String myChangeObject; 
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MetaMethod 

String myThrowsType; 
Vector myParameters; / / MetaParameter 
Vector mvBodyParts; / / String 
MetaAttribute myPassToAttribute; 
bollean myPassThisFlag; 
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MetaParameter 
String myName; 
MetaDataType myDataType; 



MetaDataType 

Vector ourTypes; / / MetaDataType 
int myToken; 
String myTokenName; 
String myJavaDeclaration; 
String myJavalnterfaceDeclaration; 
String myDatabaseDeclaration; 
String myDatabaseLength; 
MetaClass myReferenceType; 
String nnyObjectifier; 
String myDeobjectifier; 
boolean myPassByCopyFIag; 
String myCollectionContentName; 
String myNullValueString; 
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INTEGRATED THREE-TIER APPLICATION 
FRAMEWORK WITH AUTOMATED CLASS 
AND TABLE GENERATION 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

This invention relates to the field of computer software, 
and, more specifically, to multi-tier software applications. 

Portions of the disclosure of this patent document contain 
material that is subject to copyright protection. The copy- 
right owner has no objection to the facsimile reproduction 
by anyone of the patent docuxnenl or the patent disclosure as 
it appears in the Patent and Trademark OflSce file or records, 
but otherwise reserves all copyright rights whatsoever. Sun, 
Sun Microsystems, the Sun logo, SPARC, Java, JavaBeans 
and all Java-based trademarks and logos are trademarks or 
registered trademarks of Sun Microsystems, Inc. in the 
United States and other countries. 

2. Background Art 

In the computer industry, an application architecture that 
is becoming more widely used, particularly in the Internet 
environment, is the three-tier application architecture, or 
three-tier architecture. In this architecture, a client commu- 
nicates requests to a server for data, software and services, 
for example, and the server responds to the requests which 
may entail communication with a database management 
system for the storage and retrieval of persistent data. The 
three tier architecture includes a database tier that includes 
a database server, an appUcation tier that includes an appli- 
cation server and appUcation logic (i.e., software application 
programs, functions, etc.), and a client tier. The application 
server responds to application requests (e.g., a request for a 
software applet, etc.) received from the client. The applica- 
tion server forwards data requests to the database server. An 
enterprise's application (e.g., a scheduling, accounting or 
personnel application) may involve all three tiers as data that 
is used by the appUcation may be stored in a database. 

Unfortunately, in the development of three-tier 
applications, the development of the client software, the 
application server software, and the database configuration 
are performed as independent processes, often with much 
inefficiency and redundancy of design. Support for handling 
changes to and updates of data must be provided not only 
between multiple clients and the application server in a 
reliable and efficient manner, but between the application 
server and the database as well. Further, the addition of new 
forms of data, or the revision of current forms, may require 
that the client software and application server software be 
rewritten to accommodate the new or revised data structures. 

no. 2 provides an overview of a three-tier architecture. 
Chent tier 202 typically consists of a computer system that 
provides a graphic user interface (GUI) generated by a client 
206, such as a browser or other user interface application. 
Chent 206 generates a display from, for example, a speci- 
fication of GUI elements (e.g., a file containing input, form, 
and text elements defined using the Hypertext Markup 
Language (HTML)) and/or from an applet (i.e., a program 
such as a program written using the Java"^" programming 
language that runs when it is loaded by the browser). 

Further application functionality is provided by appUca- 
tion logic managed by application server 210 in appUcation 
tier 216. The apportionment of application functionality 
between client tier 202 and appUcation tier 216 is dependent 
upon whether a "thin client" or "thick cUent" topology is 
desired. Database tier 218 contains the data that is accessed 
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by the application logic in application tier 216. Database 
server 212 manages the data, its structure and the operations 
that can be performed on the data and/or its structure. 

AppUcation server 210 can include appUcations such as a 
5 corporation's schcduUng, accounting, personnel and payroll 
appUcations, for example. AppUcation server 210 manages 
requests for the appUcations that are stored therein. AppU- 
cation server 210 can also manage the storage and dissemi- 
nation of production versions of enterprise application logic 
10 (i.e., the versions that are currently being used by the 
corporate users). Database server 212 manages the database 
(s) that manage data for appUcations. Database server 212 
responds to requests to access the scheduUng, accounting, 
personnel and payroll appUcations' data, for example. 

Connection 204 is used to transmit enterprise data 
between client tier 202 and application tier 216, and may 
also be used to transfer the enterprise application logic to 
client tier 202. The client tier can communicate with the 
appUcation tier via, for example, a Remote Method Invoca- 
tor (RMl) application programming interface (API) avail- 
able from Sun Microsystems™. The RMI API provides the 
abiUty to invoke methods, or software modules, that reside 
on another computer system. Parameters are packaged and 
unpackaged for transmittal to and from the cUent tier. 
Connection 214 between application server 210 and data- 
base server 212 represents the transmission of requests for 
data and the responses to such requests from applications 
that reside in application server 210. 

Elements of the client tier, application tier and database 
tier (e.g., cUent 206, appUcation server 210 and database 
server 212) may execute within a single computer. However, 
in a typical system, elements of the cUent tier, appUcation 
tier and database tier may execute within separate computers 
2j interconnected over a network such as a LAN (local area 
network) or WAN (wide area network). 

SUMMARY OF THE INVENTION 

An integrated three-tier application framework with auto- 

40 mated class and database table generation is described. 
Schema information in the form of metadata structures is 
used to generate data classes for the client tier and the 
appUcation tier. Corresponding cUent tier and appUcation 
tier data classes implement a common interface that supports 

45 generalized access by other system components. Based on 
the schema information, factory classes are automaticaUy 
generated for the cUent tier and application tier which permit 
instantiation of the generated data classes. Also, database 
configuration is automated by the generation of database 

50 table creation commands from the schema information. 
In one embodiment, a framework of management com- 
ponents are provided for both the client and application tiers 
to handle inter-tier communication, transparent caching of 
data objects in a public store, handUng of changes to data via 

55 change objects, handling of updates in response to data 
changes, and resolution of query objects into database 
queries. Common methods are generated within each data 
class which recognize the use of a public store and the 
appUcaUon of a change object scheme. Further, methods and 

60 attributes are inherited from framework superclasses that 
confer the concept of identity on a data class, as weU as the 
abiUty to discover the attributes of the data class. 

BRIEF DESCRIPTION OF THE DRAWINGS 

65 FIG. 1 is a block diagram of one embodiment of a 
computer system capable of providing a suitable execution 
environment for an embodiment of the invention. 
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FIG. 2 is a general block diagram of a three-tier system. the change objects may be applied to the corresponding data 
HG. 3 is a block diagram of a three-tier application ^^i^^ the object caches. Updates of changes made are 
framework in accordance with an embodiment of the inven- propagated to interested components via update manage- 
jj^^ ment components on the client and appucation tiers. Change 
„ ^ - .5 objects and query objects are transmitted between the client 
FIG. 4 IS a flow diagram of a process for generating application tiers by communication management corn- 
classes and database tables in accordance with an embodi- p^^^^^^ ^-^^ serialization and reflection techniques. 

ment of the mvention. ™ j » j * » * *• ♦ „. * 

lo accommodate data structures tor new enterprise 

FIGS. SAandSB are blockdiagrams illustrating metadata applications, a developer provides schema information 

structures in accordance with an embodiment of the inven- ^^out the data classes. A code generator converts the schema 

t^°"- information into metadata structures and generates data class 

FIG. 6A is a flow diagram of a process for generating data definitions for the client tier and application tier that can 

classes from schema metadata in accordance with an interface with the framework management components, 

embodiment of the invention. class factories are also generated that provide factory meth- 

FIG, 6B is a flow diagram of a process for generating a 15 ods for creating new instances of the data classes. The 

class definition from a MetaClass instance in accordance schema information in the metadata structures is used by the 

with an embodiment of the invention. code generator to generate a schema class that can configure 

FIG. 7A is a flow diagram of a process for generating the database, at runtime, by generating "create table" com- 

database "create table" commands from schema metadata in mands to support the persistent attributes of the data classes, 

accordance with an embodiment of the invention. 20 A more efiBcient development process is thus achieved with 

FIG. 7B is a flow diagram of a process for generating an automated generation procedures that assist in integrating 

attribute database declaration from schema metadata in ^^^a classes with the three-tier application framework, 

accordance with an embodiment of the invention. A description is given below of an embodiment of a 

FIG. 8 is a block diagram iUustrating the use of data computer apparatus suitable for providing an execution 

objects, change objects and query objects, in accordance 25 environment for the software apparatus of the invention, 

with one embodiment of the invention. Embodiment of Computer Execution Environment 

FIG. 9 is a block diagram of design time and run time ^ ^ ^ u * p.u • u ■ ^ ♦ ^ 

, . J ..u u J- * f *i. An embodiment of the mvention can be implemented as 

environments in accordance with an embodiment 01 the ^ - • .i_ * c * j ui j 

computer software in the form of computer readable code 

inven ion. executed on a general purpose computer such as computer 

DETAILED DESCRIPTION OF THE iUustrated in FIG. 1, or in the form of bytecode class 

INVENTION files executable within a Java runtime environment running 

^ ^ . , . . on such a computer. A keyboard 110 and mouse 111 are 

The invention is an integrated three-tier application ^^^^^^^ ^ bi-directional system bus 118. The keyboard 

framework with automated class and database table genera- 35 introducing user input to the computer 

tion. In the following description, numerous specific details ^^^^^^ communicating that user input to processor U3. 

are set forth to provide a more thorough description of ^^^^ ^^-^^^^^ ^ ^^^^^^ ^^^ition to, or 

embodiments of the mvenUon. It will be apparent, however, ^^^^ ^ keyboard 110. I/O (input/ 

to one skilled in the art, that the invention may be practiced ^ bidirectional system bus 118 

without these specific details. In other instances, weU known represents such I/O elements as a printer, AfV (audio/video) 

features have not been described m detail so as not to yQ 

obscure the invention. Computer 100 includes a video memory 114, main 
An embodiment of the invention comprises a three-tier memory 115 and mass storage 112, all coupled to bidirec- 
application framework having system management compo- tional system bus 118 along with keyboard 110, mouse lU 
nents that handle the representation of data in the form of 45 and processor 113. The mass storage 112 may include both 
data objects on the client tier and server tier. The data objects g^ed and removable media, such as magnetic, optical or 
implement a common interface whether the data objects are magnetic optical storage systems or any other available mass 
resident on the client tier or the application tier. Application- storage technology. Bus 118 may contain, for example, 
specific logic on the client tier and application tier may thirty-two address lines for addressing video memory 114 or 
access the data objects in the same manner, with storage and 50 main memory 115. The system bus 118 also includes, for 
retrieval of persistent information in the database occurring example, a 32-bit data bus for transferring data between and 
transparently to the application specific logic. among the components, such as processor 113, main 
An object cache is provided on the client tier and the memory 115, video memory 114 and mass storage 112. 
application tier to return pointers to data objects in response Alternatively, multiplex data/address lines may be used 
to object IDs. Application queries are performed via query 55 instead of separate data and address lines, 
objects. A query object is resolved against the object cache Iq one embodiment of the invention, the processor 113 is 
if the query object contains only object IDs. Otherwise, the a microprocessor manufactured by Motorola, such as the 
query object is converted into a database query. The results 680X0 processor or a microprocessor manufactured by Intel, 
of a database query are packaged into one or more data such as the 80X86, or Pentium processor, or a SPARC™ 
objects and returned. 60 microprocessor from Sun Microsystems, Inc. However, any 
Changes to data are handled via change objects that other suitable microprocessor or microcomputer may be 
encapsulate the changes being made. Change objects are utflized. Main memory 115 is comprised of dynamic random 
produced automatically by data objects, and propagated access memory (DRAM). Video memory 114 is a dual- 
transparently from the originating tier to the database tier in ported video random access memory. One port of the video 
a transaction -based scheme by change management compo- 65 memory 114 is coupled to video amplifier 116. The video 
nents in the client and application tiers. As the change amplifier 116 is used to drive the cathode ray tube (CRT) 
objects propagate through the client and application tiers, raster monitor 117. Video amplifier 116 is well known in the 
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art and may be implemented by any suitable apparatus. This 
circuitry converts pixel data stored in video memory 114 to 
a raster signal suitable for use by monitor 117. Monitor 117 
is a type of monitor suitable for displaying graphic images. 

Computer 100 may also include a communication inter- 5 
face 120 coupled to bus 118. Communication interface 120 
provides a two-way data communication coupling via a 
network link 121 to a local network 122. For example, if 
communication interface 120 is an integrated services digital 
network (ISDN) card or a modem, communication interface lo 

120 provides a data communication connection to the cor- 
responding type of telephone line, which comprises part of 
network link 121. If communication interface 120 is a local 
area network (LAN) card, communication interface 120 
provides a data communication connection via network link 15 

121 to a compatible LAN. Wireless links are also possible. 
In any such implementation, communication interface 120 
sends and receives electrical, electromagnetic or optical 
signals which carry digital data streams representing various 
types of information. 20 

Network link 121 typically provides data communication 
through one or more networks to other data devices. For 
example, network link 121 may provide a connection 
through local network 122 to local server computer 123 or 
lo data equipment operated by an Internet Service Provider 25 
(ISP) 124, ISP 124 in turn provides data communication 
services through the world wide packet data communication 
network now commonly referred to as the "Internet" 125. 
Local network 122 and Internet 125 both use electrical, 
electromagnetic or optical signals which carry digital data 30 
streams. The signals through the various networks and the 
signals on network link 121 and through communication 
interface 120, which carry the digital data to and from 
computer 100, are exemplary forms of carrier waves trans- 
porting the information. 35 

Computer 100 can send messages and receive data, 
including program code, through the network(s), network 
link 121, and communication interface 120. In the Internet 
example, remote server computer 126 might transmit a 
requested code for an application program through Internet 40 
125, ISP 124, local network 122 and communication inter- 
face 120. In accord with the invention, one such downloaded 
application is the apparatus for the integrated three-tier 
application framework described herein. 

The received code may be executed by processor 113 as 45 
it is received, and/or stored in mass storage 112, or other 
non-volatile storage for later execution. In this manner, 
computer 100 may obtain application code in the form of a 
carrier wave. 

Application code may be embodied in any form of 50 
computer program product. A computer program product 
comprises a medium configured to store or transport com- 
puter readable code, or in which computer readable code 
may be embedded. Some examples of computer program 
products are CD-ROM disks, ROM cards, floppy disks, 55 
magnetic tapes, computer hard drives, servers on a network, 
and carrier waves. 

The computer systems described above are for purposes 
of example only. An embodiment of the invention may be 
implemented in any type of computer system or program- 60 
ming or processing environment. 
General Software Apparatus 

An embodiment of the invention includes software appa- 
ratus comprising a collection of components configured to 
support an integrated three-tier architecture. The compo- 65 
nents may be implemented as one or more instances of 
object classes in accordance with known object-oriented 



programming practices, or the components may be imple- 
mented under one or more component model definitions. 
Several component model definitions are currently 
available, such as COM, CORBA, and the Java component 
scheme referred to as JavaBeans'^". 

Each component model provides for encapsuJation of 
related functions and data structures into individual 
components, similar to what occurs under a standard object- 
oriented programming (OOP) approach. The particular 
mechanisms by which the components are managed and 
interact are defined according lo the respective component 
model. Bridges (e.g., ActiveX) may be constructed which 
allow components designed under different component 
model definitions to interact within a single application. 
Interaction is typically performed through a set of methods 
implemented by the component. These sets of methods are 
referred to as "interfaces" in some component models. The 
public methods by which OOP object classes interact are 
often presented in the form of application programming 
interface (API) definitions. 

To provide a better understanding of encapsulation of 
related data structures and methods, an overview of object- 
oriented programming is provided below. 

Object-Oriented Programming 

Object-oriented programming is a method of creating 
computer programs by combining certain fundamental 
building blocks, and creating relationships among and 
between the building blocks. The building blocks in object- 
oriented programming systems are called "objects." An 
object is a programming unit that groups together a data 
structure (one or more instance variables) and the operations 
(methods) that can use or afifea that data. Thus, an object 
consists of data and one or more operations or procedures 
that can be performed on that data. The joining of data and 
operations into a unitary building block is called "encapsu- 
lation." 

An object can be instructed to perform one of its methods 
when it receives a "message." A message is a command or 
instruction sent to the object to execute a certain method. A 
message consists of a method selection (e.g., method name) 
and a plurality of arguments. A message tells the receiving 
object what operations to perform. 

One advantage of object-oriented programming is the way 
in which methods are invoked. When a message is sent to an 
object, it is not necessary for the message to instruct the 
object how to perform a certain method. It is only necessary 
to request that the object execute the method. This greatly 
simplifies program development. 

Object-oriented programming languages are predomi- 
nantly based on a "class" scheme. The class-based object- 
oriented programming scheme is generally described in 
lieberman, "Using Prototypical Objects to Implement 
Shared Behavior in Object-Oriented Systems," OOPSLA 86 
Proceedings, September 1986, pp. 214-223. 

A class defines a type of object that typically includes both 
variables and methods for the class. An object class is used 
to create a particular instance of an object. An instance of an 
object class includes the variables and methods defined for 
the class. Multiple instances of the same class can be created 
from an object class. Each instance that is created from the 
object class is said to be of the same type or class. 

To illustrate, an employee object class can include "name" 
and "salary" instance variables and a "set_salary" method. 
Instances of the employee object class can be created, or 
instantiated for each employee in an organization. Each 
object instance is said to be of type "employee." Each 
employee object instance includes "name" and "salary" 
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instance variables and the "set_salary" method. The values ActiveX bridges) may be used with JavaBeans to allow 

associated with the "name" and "salary*' variables in each JavaBeans to be used in other component model 

employee object instance contain the name and salary of an environments, such as OLE/COM and CORBA. 

employee in the organization. A message can be sent to an Support for features such as "introspection," 

employee's employee object instance to invoke the "set_ 5 "customization " "events " "properties" and "persistence" is 

salary" method to modify the employee's salary (i.e., the provided within the JavaBean framework to facilitate appli- 

value associated with the "salary" variable in the employee's cation building and component use. "Introspection" permits 

employee object). builder tools to analyze how a particular bean works. "Cus- 

A hierarchy of classes can be defined such that an object tomization" permits an application builder to customize the 
class definition has one or more subclasses. A subclass lo appearance and behavior of a bean. "Events" provide a 
inherits its parent's (and grandparent's etc.) definition. The simple communication metaphor that can be used to connect 
parent class is also referred to as a "superclass." Each a bean with other application components or beans. "Prop- 
subclass in the hierarchy may add to or modify the behavior crties" are used for bean customization and programmatic 
specified by its parent class. Some object-oriented program- use. "Persistence" allows for a bean to have its customized 
ming languages support multiple inheritance where a sub- is state saved and reloaded later. These features are discussed 
class may inherit a class definition from more than one in the JavaBean API Specification, Version 1.01, by Sun 
parent class. Other programming languages, such as the Java Microsystems (1997), which is available on the World Wide 
programming language, support only single inheritance, Web atthe URL, "http://java.sun.com^eans/spec.htm^^ and 
where a subclass is limited lo inheriting the class definition is incorporated herein by reference, 
of only one parent class. The Java programming language 20 Embodiments of the software apparatus may be imple- 
also provides a mechanism known as an "interface" which ^^ented using standard OOP object classes or using compo- 
compnses a set of constant and abstract method declara- ne^ts under a known component model definition. For the 
tions. An object class can implement the abstract methods purposes of the following description, references to compo- 
defined in an mterface. ^^^^ ^^^^^ ^ ^^^^ instances of OOP object 

An object is a generic term that is used in the object- 25 classes, or one or more components under a known com- 

oriented programming environment to refer to a module that ponent model 

contains related code and variables. A software application lenjenUtion of Hiree-Tier Framework 

can be wntten using an object-oriented programming Ian- , , . , 

guage whereby the program's functionality is implemented , ^^^^ ^ ^.^^"^^ 'l'='8"°' °f miplementaUon of a 

using objects. As previously discussed, the encapsulation 30 ttree-tier apphcation framework m accordance with an 

provided by objects in an object-oriented programming embodiment of the invention. The three-Uer apphcation 

environment may be extended to the notion of components ^^r"^,^^^?"^? °' ^'J^'"^' ^ " 

under a component model definition. ^OOA and 300B, m the chenl tier, apphcation server 307 m 

Implementation in the Java Programming Language application tier and databa^ server 311 in the database 

An embodiment of the software apparatus of the invention 35 ■ As represented by hnes 30Mlients 300A and 300B are 

is implemented in the Java programming language. TTie Java "'"Pj^'' to application ^^fv^f 307 to exchange method caUs 

. „ i„„„,,.,„^ :^ „ ui^^t ^^^^t^A and data. As represented by hne 310, application server 3(i7 

programming language is an object -onented programming . , , .'^ , ^ , . , 

^r.„Z.„„^ „ritu ^^^u ^ ™™ «u:^^t IS coupled to database server 311 to exchange database calls 

language wiln each program compnsing one or more object ^ T t . , , , . . 

classes. Unlike many programming languages, in which a ^"it P^^^^^^, embodiments for 

program is compiled into machine-dependent, executable 40 additional servers to be coupled to apphcation server 307 for 

program code, Java classes are compiled into machine the exchange of enterprise data. 

independent bytecode class files. Each class contains code Within the client and application tiers, data is maintained 
and data in a platform-independent format called the class in the form of data objects. Application server 307 maintains 
file format. The computer system acting as the execution a set of objects containing data for the chents it serves, 
vehicle supports the Java runtime environment. The runtime 45 Clients 300A and 300B each maintain a subset of objects 
environment contains a program called a virtual machine, containing data for their respective user needs. Application 
which is responsible for executing the code in Java classes. server 307 is responsible for transforming data from the 
Applications may be designed as standalone Java format of database server 311 into the form of data objects, 
applications, or as Java "applets" which are identified by an and, similarly, from the form of data objects into the format 
applet tag in an HTML document, and loaded by a browser so of database server 311. Additionally, queries are transformed 
application. The class files associated with an application or from a general query object format into the particular query 
applet may be stored on the local computing system, or on format expected by database server 311, such as SQL. 
a server accessible over a network. Each class is loaded into Clients 300A and 300B comprise client-side application 
the Java runtime environment, as needed, by the "class logic and graphic user interface (GUI) component 301A, 
loader." 55 client-side change management component 302A, client- 
Java classes are loaded on demand from the network side object cache component 303 A, client -side update man- 
(stored on a server), or from a local file system, when first agement component 304 A, client -side communication man- 
referenced during an application or applet's execution. The agement component 305A and client-side query 
runtime environment locates and loads each class file, parses management component 3 12 A. Application server 307 com- 
the class file format, allocates memory for the class's various 60 prises server-side communication management component 
components, and links the class with other already loaded 305B, server-side application logic 301B, server-side 
classes. This process makes the code in the class readily change management component 302B, server-side object 
executable by the virtual machine. cache component 303B, server-side update management 
Java classes may also be incorporated into Java compo- component 304B, server-side query management compo- 
nents referred to as "JavaBeans". JavaBeans are designed in 65 nent 312B, data store component 308 and database connec- 
accordance with the JavaBean API Specification to allow for tivity component 309 (e.g., a Java data base connectivity or 
component-based application building. Bridges (e.g., JDBC™ component). 
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Gient-Side Components 

Client-side application logic and GUI component 301A 
provides the software mechanism by which the user is able 
to view the data and other output associated with a particular 
application, to generate input in the form of additions, 
deletions and modifications of data, and to otherwise exert 
control over the data and format of what is displayed. 
Client-side application logic and GUI component 301A 
interfaces with client-side change management component 
302A, client-side object cache component 303A, client-side 
update management component 304A and client-side query 
management component 312A. 

Gient-side change management component 302A pro- 
vides the software mechanism by which changes to data are 
handled within the respective client. This entails determin- 
ing which objects within the client are affected by a change 
and carrying out the change on those objects. Also, the 
change is propagated to the application server for handling. 
In one embodiment, changes are abstracted into change 
objects. The change object, for example, may contain the 
state of a given data object before a change is applied, as 
well as the slate of the given data object after the change is 
applied. Custom change objects for specific data classes may 
be subclassed from general framework change object super- 
classes. Client-side communication management component 
305A is used to transmit a change object to application 
server 307, or to receive a change object from application 
server 307. 

Client-side object cache component 303A maintains a set 
of objects for the respective client, as well as a hash table of 
the unique ID of each object thus maintained and an asso- 
ciated pointer to that object. When a user makes a request for 
data via client-side application logic and GUI component 
301A, client-side object cache component 303A is first 
queried to determine whether the data object containing the 
desired data is already resident at the client. If the data object 
is resident, as indicated by the presence of its object ID in 
the hash table, client-side object cache component 303A 
returns to the requesting logic a pointer to the data object. If 
the object is not resident at the client, client-side cache 
component 303 A sends a request for the given object to 
application server 307. When the desired object is transmit- 
ted from application server 307 to the requesting client, a 
pointer to the object is returned to the requesting application 
logic, and the object is registered in the hash table for future 
requests. 

To maintain control over the number of data objects 
resident in the client, client-side cache component 303A 
may perform what is referred to as "pruning the cache." This 
means that certain data objects are removed from client -side 
cache component 303Aby removing their entries in the hash 
table. Data objects whose entries have been removed from 
the hash table may then be garbage collected by the system. 

Reference counting may be used to determine which 
objects are currently in demand, or more advanced interest 
registries may be used for such a purpose. In reference 
counting, a reference count value associated with a given 
cache object is incremented whenever another referencing 
object obtains a reference to the cache object. The reference 
count value is decremented whenever a referencing object 
indicates the reference to the cache object is no longer 
needed. When the reference count is at zero, no other objects 
maintain a reference to the cache object, and it may be safely 
removed from the object cache and garbage collected. 

With a more advanced interest registry, interest objects 
may be used to indicate that one or more objects are 
"interested" in actions involving a particular data object in 
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the cache (i.e., a cache objea). These interest objects can 
thus be used to determine which cache objects are subject to 
registered interest and which are not. Those cache objects 
for which no interest objects are registered may be safely 

5 removed from the object cache. 

Client -side query management component 312 A provides 
a mechanism for formulating application queries, and, either 
resolving those queries against client-side object cache 
309A, or forwarding those queries to application server 307 
for handling. Object requests or queries from application 
logic are typically encapsulated within one or more query 
objects. If a query object contains only object IDs, the query 
object may be resolved against the object cache. If a query 
object contains query information other than object IDs, the 
query object is transmitted to application server 307 to be 

1^ resolved into an appropriate database query for the database 
server. Responses to the database query are encapsulated 
into one or more data objects and returned to the requester. 
The hash tables of the respective object cache components 
are updated to include the new data objects. 

20 Custom query objects with application specific semantics 
may be subclassed from general framework query object 
superclasses. Further, query object subclasses may extend 
interest-based object superclasses that implement active 
updating through registration of interest objects that identify 

25 the query requester with the data objects resulting from the 
query. 

Client -side update management 304A provides the soft- 
ware mechanism by which updates are applied to data 
objects and other associated objects within the respective 

30 client. For example, in one embodiment, client-side update 
management component 304A implements an active updat- 
ing scheme. This means that not only is a data object affected 
by changes in the form of an addition, deletion or modifi- 
cation of associated data, those objects in client -side appli- 

35 cation logic and GUI component 301 A that are dependent on 
the associated data are also updated. This is opposed to a 
passive update scheme wherein objects in client-side appli- 
cation logic and GUI component 301A would not be aware 
of changes to data until and unless a fiirlher reference is 

40 made to the respective data object, at which time the data 
object would determine whether an update is necessary. 

One method for implementing the active updating scheme 
is to apply interest objects as discussed briefly above. Query 
objects result in the registration of an interest object for the 

45 requester. Any changes to data objects passed as a result of 
the query will be propagated to the interested component 
indicated in the registered interest object. Further descrip- 
tion of the interest scheme is provided in copending U.S. 
patent application Ser. No. 09/092,356, entitled "Method 

50 and Apparatus of Performing Active Update Notification," 
filed on Jun. 5, 1998, assigned to the same assignee, and 
incorporated herein by reference. 

Client-side communication management component 
305A provides the software mechanism by which objects 

55 and method calls are transmitted between the client (300 A or 
300B) and application server 307. In accordance with an 
embodiment of the invention, objects that may be transmit- 
ted between the client and application tiers are configured 
with metadata describing the elements of the object, such as 

60 the attribute names and types, methods, etc. Objects con- 
figured with metadata can be serialized, that is, broken down 
into a set of data bytes containing the metadata descriptions 
and object state which may later be reconstituted (i.e., 
"deserialized") by the same or a different application to 

65 generate a copy of the original object. 

Serialization provides a useful mechanism for object 
persistence and transmission. With respect to persistence, a 
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serialized object may be stored in memory for any length of performed. "Redo" functions are also easily implemented. In 

time and regenerated with the same state the object had at one embodiment, change objects may be collected on a 

the time it was serialized. With respect to object client while the client is ofiQine from an application server, 

transmission, a serialized object may be transmitted between When the client is once again connected to the application 

remote clients and servers as data streams or packets in 5 server, the change objects may be applied to the application 

accordance with known communication protocols, such as server. 

the protocol implemented by the Remote Method Invocator Server-side object cache component 303B is similar to the 

(RMI) API. Also, serialized objects may be written to a client-side object cache component 303A. When a data 

shared portion of memory by one application and read out of object request or query object is received from a client or 

the shared memory by another application. Client-side and lO from the server-side application logic 301B, the request is 

server-side communication management components 305A resolved against the cache, if possible, by specifying the 

and 305B implement methods to perform serialization and object ID in the hash table. If a data object is already 

deserialization functions. Data transport, such as the trans- registered with the object cache component 303B, a pointer 

mission and reception of serialized objects, may be imple- to that object is returned. If the object is not registered with 

mented using any known communication protocol as 15 object cache component 303B, datastore management com- 

described above, ponent 308 is utilized to obtain the desired object or objects 

Server-Side Components from the persistent store of database server 311. The newly 

Server-side communication management component obtained data object is registered with object cache compo- 

305B performs the same general functions for application nent 303B, and the pointer to the data object is returned to 

server 307 as its counterpart component 305A does for client 20 the query sender. 

300A or 300B, such as serialization, deserialization, and Server-side update management component 304B acts in 

data transport. Method calls and objects received by the association with change management component 302B to 

server-side communication management component from ensure that notices regarding changes to data are transmitted 

client-side communication management component 305A to all interested elements of the system. Under the active 

are directed to server-side components 301 B, 302B, 303B, 25 notification scheme using interest objects, update manage- 

304B and 312B as specified by the call either explicitly or menl component 304B maintains a registry of clients and 

implicitly. Method calls or objects destined for the client tier other servers that wish to be notified when a designated data 

are directed to the client-side communication management object is changed. When a change is made, interested 

component 305 A of the specified client, 300A or 300B. elements within application server 307 and interested clients 

Server-side application logic 301 B provides any 30 receive notification of the change. Notification within each 

application-specific functions for application server 307, client is typically resolved by the respective client-side 

such as data analysis and processing algorithms, etc. Further, update management component 304A. 

automated data functions, such as time-based operations. Server-side query management component 312B receives 

and multi-client oriented operations may be implemented by query objects from the client tier, from other application 

server-side application logic 301B. These functions may 35 servers, or from components of application server 307. 

also include the implementation of a permissions model for Query objects thus obtained are resolved against server-side 

determining access permissions and change permissions for object cache 303B if only object IDs are specified by the 

different clients or users. The division of application-specific query. If the query object cannot be resolved against object 

functionality between client-side application logic and GUI cache 303B, either because the requested objects IDs are not 

component 301A and server-side application logic 301B 40 in the hash table or because the query is not in the form of 

may be determined by the relative efficiency of shared object IDs, query management component 312B passes the 

functions on a server versus local funaions on a client. Also, query object to datastore management component 308 to be 

the use of a thin client or thick client topology may deter- processed, 

mine how functions are divided between clients 3(K)A and Datastore management component 308 responds to calls 

300B and application server 307. 45 from the server-side change management component 302B 

Server- side change management component 302B pro- by making API calls to JDBC component 309 to create, 

vides for the application of changes, for example, in the form delete or mutate persistent data within database server 311. 

of change objects, to data objects in application server 307. Datastore management component also responds to query 

Change objects may be received from either of clients300A objects by submitting database requests to the database 

or 300B (or from other servers). The changes embedded 50 server. The results of the database requests are then encap- 

within change objects are used by datastore management sulated into one or more corresponding data objects. If a data 

component 308 to send appropriate calls to database server object resulting from a query is already in the server-side 

311 to manipulate the persistent data stored therein. In one object cache component 303B, the cached data object is 

embodiment, as part of a change operation, a call may be returned. If the data object is not in server-side object cache 

made to one or more permissions objects in the application 55 component 303B, a new data object is obtained, via factory 

logic component 301 B, to determine whether the encapsu- method calls directed to a data class factory object, to 

lated change is allowed. The change may then be undone at encapsulate the data. Typically, the factory method calls 

the client if the change is not permissible, or the change may result in the instantiation of a desired data object class, 

be carried out on the application server and propagated to the However, in other embodiments, the new data object may be 

database if the change is permissible. 60 obtained from a pool of available data object instances. The 

In one embodiment, changes are handled within a trans- new data objects are assigned ID numbers, loaded with 
actional scheme. Change objects allow several benefits in a appropriate data from database server 311, and returned, 
transactional scheme. For example, change objects may be Datastore management component 308 performs the con- 
stored on a stack after the associated changes have been version from queries encapsulated in query objects to cor- 
performed. The stack of change objects may then be used to 65 responding database calls by resolving the queries with 
perform transaction rollbacks, that is, the change objects database tables. The JDBC component 309 provides the 
may be used to "imdo" or reverse the changes previously conversion between general database calls made by datas- 
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tore management component 308 and database-specific side object cache 303B, respectively. As part of the query 
commands (e.g., SQL) and communication protocol process, interest in data objects 801 A and 801B is registered 
required by the particular implementation of database server with update management components 304A and 304B, as 
311 (e.g., Oracle, Sybase, etc.). Connection 310 represents shown by arrows 809 and 810, respectively, 
the communication link between JDBC component 309 and 5 FIG. 9 illustrates relationships between the design time 
database server 311. In some embodiments, other database and run lime environments of an embodiment of the inven- 
connectivity components may be used in place of or in tion. The design time environment is associated with the 
addition to JDBC component 309. generation of class definitions for one or more data classes, 
Database server 311 may be any form of structured a factory class and a schema class, based on application- 
persistent store. For example, database server 311 may lO specific schema metadata. The run time environment is 
comprise a flat-file data management system, a relational associated with the execution of the three-tier application (as 
database management system (RDBMS), an object-oriented illustrated in FIGS. 3 and 8) in which instances of the classes 
database management system (ODBMS), etc. Typically, the generated in the design lime environment are integrated with 
organization of the database may be represented by one or the components of the three -tier application. For example, 
more database tables wherein each column of the table 15 data objects in the run time environment are created as 
represents a particular data attribute having a specified instances of the data glasses generated in the design time 
database type. Each row represents a set of attribute values environment. An instance of the generated factory class is 
associated with a particular index. In one embodiment, each used in the run time environment to obtain the data object 
row of a database table is associated with a particular data instances. Also, an instance of the generated schema class is 
object, and each table is associated with a data object class. 20 used in the run time environment to structure the database at 
Each column therefore specifies an attribute of the given initial start-up, and to provide a facility for accessing schema 
data object class. In other embodiments, the database orga- metadata at run time. 

nizalion may be independent of the data object classes in the As shown, the design time environment comprises 

client and application tiers. The datastore management com- schema metadata 900, code generator 901, and generated 

ponent 308 handles mapping of the data objects to the 25 code 902. Generated code 902 further comprises client data 

database. In accordance with an embodiment of the class 903, data object interface 904, application (i.e., server) 

invention, the database tables are generated during, or prior data class 905, factory class 906 and schema class 907. In 

to, system start-up from schema information. accordance with an embodiment of the invention, one client 

FIG. 8 illustrates the use of data objects, change objects data class 903, one data object interface 904 and one 

and query objects in the client and application tiers in 30 application data class 905 are generated for each data class 

accordance with one embodiment of the invention. The described by schema metadata 900. Data classes 903 and 

client tier comprises application logic 301 A, object cache 905 include metadata describing the attributes and methods, 

303A, and update management component 304A. The appli- for example, of the respective class. Schema class 907 

cation tier comprises object cache 303B, datastore manage- includes metadata describing the data management of the 

ment component 308 and update management component 35 system in terms of metaclasses and their constituent ele- 

304B. In addition, data objects 800A and 800B reside in menls. The processes of code generation in the design lime 

object cache 303 A and object cache 303B, respectively. environment are described in further detail in following 

When application logic makes a change to data object sections of this specification. 

800A, as indicated by arrow 804, a transaction is initiated The run time environment comprises the components of 

that includes the creation of a change object and the propa- 40 the client, application and database tiers as earlier described 

gallon of that change object to the database. Change object with respect to FIG. 3, For example, the client tier comprises 

802 is transmitted to the application tier, as indicated by one or more clients (300A) having application logic and 

arrow 805, where change object 802 is applied to corre- GUI component 301 A, change management component 

sponding data object 800B. Changed data object 808 is then 302 A, object cache component 303A, update management 

applied to the database through datastore management com- 45 component 304A, query management component 312A and 

ponent 308, as indicated by arrow 806. communication management component 305A. The appli - 

As one of the steps in the change transaction, update cation tier comprises one or more application servers (307) 

management component 304B is informed of the change, as having communication management component 305B, 

indicated by arrow 807. Interested clients are identified by application logic 301B, change management component 

update management component 304B, and a notice of the 50 302B, object cache component 303B, update management 

change is transmitted to the update management component component 304B, query management component 312B, 

304A of the interested clients, as indicated by arrow 812. datastore management component 308 and JDBC compo- 

The client update management component 304A then nent 309. The database tier comprises one or more database 

determines, based on an interest registry, which elements on servers (311). The client and application tiers are joined by 

the client should receive notificationof the change. The data 55 connection 306, and the application and database tiers are 

objects in object cache 303A are typically updated at the joined by connection 310. 

time the client is notified of the change. As shown, handling of change objects, such as change 

When application logic 301 A makes a database query that application and forwarding operations, is performed by 

cannot be resolved directly by an object cache, the query is change management components 302A and 302B at the 

transmitted, as shown by arrow 808, to datastore manage- 60 client and server tiers. Query management components 

ment component 308 in the form of query object 803. 312A and 312B at the client and server tiers handle query 

Transmission of query object 803 is performed under man- object operations, such as resolving queries against a respec- 

agement of chent-side and server-side query management tive object cache or forwarding to another tier or to the data 

components (not shown). In response to the query, datastore store component for handling. Object cache components 

management component 308 returns, as shown by arrow 65 303 A and 303B manage data objects for client 300A and 

811, corresponding data objects 801A and 801B which are application server 307, respectively. As suggested above, the 

registered with the client-side object cache 303A and server- client data objects are obtained for object cache component 
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303A in the form of instances of client data classes 903 notify all interested conoponents of client 300A of the 

generated in the design time environment. Similarly, appli- updated data objects. The transaction is completed when the 

cation data objects in object cache component 303B are initiating element of application logic and GUI component 

obtained in the form of instances of application data classes 391 a receives notification of the changed data objects. 
905. Corresponding data objects in the client and application 5 !„ another embodiment, the change objects may be 

tiers implement the same shared data object interface 904 j^^^ ^^^^ ^^-^^^ ^^-^^^ ^^^^^ component 303A 

generated in the design time environment. ^, ^-^^ ^„ .^^^ transaction" is signalled. In this case, 

In FIG. 9, arrow 908 is used to illustrate the propagation ^^^^^ ^^^^^ component 303A would not need updating just 

of a change transaction through the three-tier system. The p^or to notifying update management component 304A of 
transaction begins in application logic and GUI component jg the updated data objects. However, any "undo" operation 

301A, when the application logic initiates a change to a data would include undoing data object changes in object cache 

object, for example, by calling one of the data object's component 303A. 

attribute "set" accessor methods. In response to the method Use of Schema and Embodiment of Metadata Structures 
call, the data object calls change management component accordance with one embodiment of the invention, 
30M, where a corresponding change object is obtained. 15 metadata is associated with each data object class. The 
Change management component 302A adds the change metadata describes the elements of each data class in terms 
object to a list of change objects associated with a single of> fo^" example, attribute and method names, parameters, 
transaction. Other change objects may be added to the list «lata types, inter-class relationships, etc. The "schema" is a 
before the transaction is closed, for example, due to receipt description of the three-tier system, and composes the 
of an "end of transaction" call. metadata for all of the data classes associated with the 
When the transaction is closed, change management com- ^y^^^^J; The^h^n^a is utilized in the design time environ- 
ponent 302A provides the list of change objects to commu- "^^"^ ('-^ ^ ^^"^8 the building stage of development) to 
nication management component 305A. Communication automate production of data class definitions for the client 
management component 305A serializes and transmits the application tiers, and to automate producUon of a factory 
list of change objects to communication management com- class for instantiating those data classes. Redundant pro- 
ponent 305B at application server 307. Communication gramming is therefore reduced. Further, data class defini- 
managcment component 305B deserializes the list of change tions generated in this manner can be easily configured with 
objects and provides them to change management compo- interfaces that conform to expected data object specifica- 
ncnt 302B. Change management component 302B then tions for integration with other components of the three -tier 
applies the list of change objects to the application data system. 

objects in object cache component 303B. The updated data A schema object may be generated that contains the 

objects in object cache component 303B are passed to data schema metadata for informational access by components of 

store management component 308. Datastore management the three -tier system. Components may access the metadata 

component 308, in association with JDBC component 309. in instances of these metaclasses at runtime to determine the 

converts the updated data objects into database calls (e.g., attributes that make up the associated data class and the 

SQL calls) to database server 311 to update the database methods for interfacing with that data class, 

records corresponding to the updated data objects. The schema is also utilized to create the database tables 

If the transaction fails at the database server, change that are used to organize the database. By extracting the 

management component 302B uses the list of change objects attribute names and associated data types for persistent data 

to "undo" the changes made to the data objects in object i^i each data class, as defined in the schema metadata, 

cache component 303B and sends notification to client 300A commands, such as SQL "create table" commands, can be 

that the transaction failed to commit. If the datastore man- generated and used by the datastore component to structure 

agement component 308 receives confirmation of a success- the database at start-up. 

ful update from the database server, update management 45 FIG. 4 is a flow diagram illustrating a process for utilizing 

component 304B is notified of the updated data objects in system schema to build a three-tier application with auto- 

^u'^^t iniTi ii^A^t^ mated code generation in accordance with an embodiment of 

object cache component 3U3B. Update management com- , . . ^ , , , , . . 1 

, „ . , , , , ,. the invention. In step 400, the schema describmg the data 

ponent notifies all interested components on application ^^^^^^ ^^^^^ ^ ^^^^^^^ 

server 307, and sends update notifications to all other metadata for the data classes is extracted from the schema, 

mterested servers and mterested clients. metadata thus extracted is used, in step 402, to create 

The update notification to the cUent includes the updated data class definitions (e.g., ".java" files) for the appfication 

data objects. Communication management component 305B tier and the client tier. The actual implementation for the 

seriafizes the data objects and transmits them to oommuni- different tiers may differ, but the attributes and method calls 
cation management component 305A. Communication man- 55 are the same. For each class, an interface definition speci- 

agement component 305A extracts the object IDs from the fying the common method interface for the application and 

serial stream and determines whether those data objects exist client tiers may also be created. In step 403, a factory class 

in object cache 303A. If a data object already exists, the is created that provides one or more factory methods for 

values of the data object are updated with the values of the obtaining instances of the data classes described by the 

corresponding serialized data object. If a data object does metadata. In step 404, database tables are created from the 

not exist in the object cache, a new data object instance is schema metadata by formulating "create table" commands 

placed in object cache component 303A and loaded with the from the class and attribute descriptions within the metadata, 

values of the corresponding serialized data object. jt will be obvious that steps 402 and 403 may be performed 

Once updated data objects have been established in object in any desired order. Step 404 is typically performed at run 
cache component 303A, update management component 55 time during initial start-up. 

304A is notified of the updated data objects in the object The schema may be provided as a text file listing the 

cache. Update management component 304A proceeds to different elements of each data class with known delimiters 
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between each element or portion of elements. An example of 
a text file schema for a data class is provided below. The 
individualized schema entries are shown within "< >" sym- 
bols. Optional entries are shown inside of parentheses. 



CLASS <cla86naine> (ABSTRACT) (INTERFACE) (PERSISTENT) 
(VERSIONr<versioninfo>") (SUPER/<supcrdassname>) 
(INTER/<mtefacename>) { 10 
IMPORTS { 

<import5tring>, 

<iinport5tring;>, 

} 



18 



command or method parameters. For example, methods 
such as newClass( ), ncwAttribute( ), newMethod( ) and 
newParameter( ) could be used to specify the entry of the 
corresponding element. Those methods may then be defined 
to facilitate the setting of metadata attribute values and Sags 
in metadata structures. By compiling the schema file and 
executing the method calls, the schema metadata may be 
extracted and loaded directly into the desired data structures, 
with the desired Bags automatically set in accordance with 
the specified methods. An example of a coded schema file 
for a sample class is provided below. The individualized 
schema entries arc shown within "< >" symbols. 



ncwClass = newCoreClass("<classname>", <superclass>); (1) 

newCla38,setQassVersion("<versioninfo>"); (2) 

addImporl("<importslring>"); (3) 

newAttribute( ).private( ).persistent( ).nonNull( ).string_( ).naine("<aUribut (4) 

enamo"); 

newAttribute( ).private( ).persistentC ).nonNuil( ).object_('*<classQames>").n (5) 
ame(** attribute na me>"); 

newMethod( ).pubUc_( ).object_("<classaaine>"),name("<methcxlnamc>"); (6) 

newParameter( ).object_("<clafisname>").iiame("<parametemame>*'); (7) 

ncwParainctcr( ).iat_( ).namc("<paramctcraamc>"); (8) 

addBodyC'<metbodstring>*'>, (9) 

addBody("<methodstrmg>"); (10) 



30 



-continued 



ATTRIBUTES { 

<attributcnamc> <datatypc> (DEFAUUr/<dcfau]tvaluc>X 
<aUributename> <dat2type> (DEFAUIT/<defau]tvalue>) 

} 

METHODS { 

■onethodnamo <datatype> (COMMENTr<cominentstring>") 
CrHROW/<cxccptioimamc>) (FRIVATE/cprivatcflagyaluo) { 
(PARAMETERS { 

<parainetername> <datatype>, 

<:paraineteriiame> <datatype> 

}) 

(BODY{ 

" <inethodstrLng>", 
" <inethodstring>" 



} 



}) 

} 

■onethodnamo <:datatypc> (COMMENT/" commcntstring") 
CrHROW/«xceptioimame>) (PRIVATE/^rivateaagvaluo) { 
(PARAMETERS { 

})' 
(BODY { 



35 
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55 



A parsing program may be used to extract the schema 
metadata from the above text file. The metadata thus 
extracted may, for example, be stored in metadata structures 
and applied to class and table generation processes within a 
generator mechanism. The above text schema format may be 
expanded to include other metadata entries not illustrated in 
the example, such as constants or relationships with other 
classes. 

The schema may also be provided in a coded format 
where the schema file is implemented as a series of com- 
mands or method calls with the schema data provided as 



60 



65 



Line (1) obtains a new metaclass instance and assigns 
class name and superclass values to metaattributes within a 
new metaclass. Line (2) sets the value of a class version 
metaattribute in the new metaclass to < version info>. Line 
(3) writes a string containing import information into an 
import data structure such as a Vector. A "Vector" is a data 
type of the Java programming language that comprises an 
array of elements that may be of any data type and of any 
length. Data types other than the Vector data type may also 
be used to store metadata. 

Line (4) establishes a new metaattribute within the meta- 
class to describe an attribute within the current class. Bool- 
ean flags within the metaattribute are set to specify that the 
attribute is private, persistent and non-null. The attribute is 
a string data type with the name <attributename>. 

The sequence of method calls coupled by "/* is typically 
evaluated from left to right. Each method call returns an 
object that acts as the implementor of the next method call 
in the sequence. For example, in line (4). the method call 
newAttribute( ) returns a metaattribute instance. The 
private( ) method of the metaattribute instance is then called 
which sets a private flag of the metaattribute and returns the 
metaattribute for the next method call. The persistent( ) 
method similarly sets a persistent flag of the metaattribute 
and returns the metaattribute, and likewise with the 

nonNull( ) method. The string ( ) method associates a 

metadatatype of type string with the current metaattribute 
and returns the metaattribute. The name( ) method sets a 
name string in the metaattribute to the value of " attribute - 
name". 

In line (5), a second metaattribute is established to 
describe a second attribute. Again, flags are set to specify 
that the attribute is private, persistent and non-null. The data 
type specified within the metaattribute is an object data type 
of the class <classname>. The name of the attribute is 
<attributename>. 

Line (6) establishes a metamethod to describe a method of 
the current class. A flag is set to specify that the class is 
public. The method returns an object data type of class 
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<classname>, and the methods name is <melhodname>. In "mylmports" is a Vector of string instances containing class 
lines (7) and (8), metapara meters are associated with the filenames for import into the current class, "my Code" is a 
metamethod of line (6). Line (7) specifies an object data type Vector of string instances describing the lines of program- 
parameter of class <classname>, and having a parameter ming code for inclusion in the current class. " my Interface- 
name of <para me temame>. Line (8) specifies an integer data 5 Code" is a Vector of string instances describing lines of 
type parameter having a parameter name of <parameler- programming code for inclusion in an interface for the 
name>. Lines (9) and (10) write individual lines of the current class. "myPassedMethods" is a Vector of 
method to a method body data structure (such as a Vector) MetaMethod instances passed by other MetaCl asses to the 
as data strings. current Meta Class instance. A "passed method** refers to the 
In the schema examples above, standard methods such as lo case where an originating class contains a method that 
constructors and accessors are not required to be specified. invokes a similarly named method of a subsequent class in 
Those standard methods are automatically generated in a which the desired method steps are implemented. The origi- 
standardized manner when class definitions are created from nating class is said to "pass" the method to the subsequent 
the metadata. Further, reflection methods, whereby other class. 

objects are able to access the attributes of an object by 15 MetaMember 502 is, in this embodiment, a superclass of 
specifying an attribute ID to a general method, may also be MetaAttribute 503 and MetaMethod 504. Thus, the 
automatically generated for each class. attributes of MetaMember 502 are included in MetaAttribute 
Simple method calls or flag indicators similar to those 503 and MetaMethod 504 by extension, as are those meth- 
shown above may be added to the schema description to ods of the superclass not overridden by the subclasses. In 
trigger the automatic generation of other standardized meth- 20 other embodiments, the elements of the MetaMember class 
ods. For example, certain classes may wish to instantiate may be explicitly defined for MetaAttribute 503 and 
other classes to fiU an object data type attribute. In this MetaMethod 504 without the use of a MetaMember super- 
instance, for example, an ofiferNewMethod ( ) call may be class. 

added to the attribute command sequence to specify the MetaMember 502 comprises an integer data structure 

automatic creation of "New** methods during class genera- 25 containing "myPrivateFlag." "myPrivateFlag" describes the 

tion. These "New** methods may use a standard "try-catch" private and protected state of the class element described by 

method formal to "try" to obtain a new instance of a data MetaMember 502. A reference, "myDataType,*' is stored lo 

class from a class factory, and to "catch" any exception a MetaDataType instance describing characteristics of the 

generated by a failure to obtain the desired class instance. data type associated with the current class element. A suing 

FIGS. 5A and 5B illustrate embodiments of metadata 30 structure, "myName," contains the name of the element as a 

structures for storing metadata in accordance with an character string. A reference, "myOwningClass," refers to 

embodiment of the invention. FIG. 5A comprises Met- the MetaClass instance describing the class of which the 

aSchema 500, MetaClass 501, MetaMember 502, MetaAt- current element is a part. Also, a Vector of su-ing data 

tribute 503 and MetaMethod 504. FIG, 5B comprises Meta- structures, "myComment," is maintained which stores, as 

Parameter 505 and MetaDataType 506. One or more values 35 character strings, lines of comments to be associated with 

within the metadata structures may be null, depending upon the current element. 

the class or class element being described by the metadata MetaAttribute 503 comprises boolean structures 

structures. " my Pe rsiste ntFlag, " "my NullFlag," 

MetaSchema 500 comprises a string data structure, "myOfiferNewMethodFlag," "myPrimaryKeyFlag" and 
"mySchema Version," that stores schema version informa- 40 "mylndexFlag." "myPersistentFlag" indicates whether the 
tion such as a version date. Also, MetaSchema 500 com- current attribute is persistent, requiring storage in the data- 
prises a Vector data structure, "myCoreClasses," containing base. "myNullFlag" specifies whether the current attribute is 
the set of Meta Classes describing the data classes of the allowed to have a null value. "myOfferNew-MethodFlag*' 
system. Further Vector structures may be defined for meta- specifies whether a "New" method is to be generated for 
classes associated with other system classes aside from data 45 obtaining a new instance of the current attribute's data type 
classes, and for the entire set of system classes including from, for example, a class factory. "myPrimaryKeyFlag*' 
data classes and non-data classes (i.e., those classes associ- specifies during database table generation that the current 
ated with system components 302A--305A, 302B-305B and attribute is a primary key for the table. "mylndexFlag" may 
306-308). A reference ("myFactoryClass") to the generated also be used during database table generation, 
factory class is also contained within MetaSchema 500. 50 MetaAt Uibute 503 further comprises the following string 

MetaClass 501 comprises a reference, "mySchema," to its data structures: "myDefault Value" specifying a default 

associated MetaSchema, and a reference, "mySuperQass," attribute value as a character string, "myMirrorCoUection- 

to the MetaClass instance describing the superclass of the ClassName" specifying the class name of the elements 

current class. String data structures, "myClassName,** contained in the Vector represented by the current attribute 

"myQass Version*' and "myChangeObject,*' store the name 55 (if applicable), "myMirrorAltributeName" specifying the 

of the class, the version of the class and the name of the name of a mirror attribute in each element of the Vector 

class's change object, respectively. Boolean flags, represented by the current attribute (if applicable), and 

"my Abs tract Flag," "myPersistentFlag" and "myChangeObject" specifying the name of the change 

"mylnterfaceFlag," indicate whether the described class is object class associated with the attribute. A reference, 

abstract, persistent and/or an interface, respectively. 60 "myMirrorCollectionClass," refers to the MetaClass 

The embodiment of MetaClass 501 shown comprises six instance describing the associated mirror collection element 

Vector data structures: "myAttributes," "my Methods," class. Also, a reference, "myMirror Attribute," refers to the 

"mylmports," "myCode," "mylnterfaceCode*' and MetaAttribute instance describing the associated mirror 

"myPassedMethods," "myAttributes" is a Vector of MetaAt- attribute. 

tribute instances describing the attributes of the current 65 A mirror collection refers to a collection or set of elements 

class. Similarly, "myMethods** is a Vector of MetaMethod where those elements are instances of a class (i.e., the 

instances describing the methods of the current class. "mirror collection class"). Each class instance within the 
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mirror coUecdon may contain an attribute (i.e., the "mirror structure "myDeobjectifier** specifies a deobjectifier. Objec- 
attribute") that is a reference to an owning class of the mirror tifiers and deobjectifiers are used respectively to convert 
collection. For example, a scheduling application may certain non-class data types into corresponding class data 
include an appointment class to represent meetings and an types, and to convert class data types into non -class data 
invitation class to represent an individual invited to attend a 5 types. For example, an objectifier may be used to convert an 
given appointment. Each appointment instance may contain integer variable into an Integer class instance containing the 
a collection (e.g., an "invitations" Vector) of invitation integer variable value, as well as certain methods for oper- 
instances representing the individuals invited to the given ating on the integer variable value. Boolean structure 
appointment. The invitation instances, in turn, contain a "myPassByCopyFlag" whether the represented data type is 
reference (i.e, a "mirror attribute") to the appointment 10 passed directly, or whether the data type is first duplicated 
instance containing the "invitations" Vector of which they with the copy being passed. String structure "myCoUection- 
are a part. In accordance with an embodiment of the ContentName" specifies, for a data type containing a col- 
invention, respective MetaClass instances are used to leclionofobjects, what the class name is for the elements in 
describe the appointment class and the invitation class. the collection. String structure "myNullValueString" stores 
Further, a "mirror collection" MetaAttribute instance within 15 the null value for the current data type. Examples of null 
the appointment MetaClass instance is used to describe the values include "null", "-1", etc. 
invitations Vector. A "mirror attribute" MetaAttribute Generation of Classes and Common Interface 
instance within the invitation MetaClass instance refers to FIG. 6Ais a flow diagram of a process, in accordance with 
the appointment MetaQass instance. an embodiment of the invention, that generates the class and 
MetaMethod 504 comprises a string structure, 20 interface definitions referred to previously with reference to 
"myThrowsType," that specifies the exception type, if any, step 402 of FIG. 4. In step 600, the schema metadata is 
thrown by the current method being described. MetaMethod obtained to facilitate the automated class generation. The 
504 comprises two Vector data structures, "my Parameters" metadata may be, for example, provided in form of the 
and "my Body Parts." "myParameters" is a Vector of Meta- metadata structures described with reference to FIGS. 5A 
Parameter instances describing the individual parameters of 25 and 5B. In step 601, the first metaclass is obtained from the 
the current method. "myBodyParts" is a Vector of string schema metadata. The metaclass comprises metadata 
structures for storing lines of method code as individual descriptions of the properties of the class, its attributes, and 
character string;5. A reference, "myPassToAttribule," refers its methods. 

to the MetaAttribute instance describing an attribute to Steps 602-604 involve building the class definition files 

forward the method call to, if applicable. A boolean 30 for the application and client tiers, as well as building the 

structure, "myPassThisFlag,*' specifies whether to include shared interface file, and may be performed in any order. In 

"this" as a parameter in a forwarded method. step 602, a class building operation is performed to write the 

MetaParameter 505 comprises a string structure, class definition for the application tier. The class building 

"myName," specifying the parameter name as a character operation uses the metadata to provide standard 

string. MetaParameter 505 further comprises a reference, 35 declarations, and to generate standard methods, such as 

"myDataType," to a MetaDataType instance describing the constructors, accessors, "new" methods and reflection meth- 

data type of the parameter. ods. The class definition is typically written to a new file in 

MetaDataType 506 comprises a Vector of MetaDataType a location within the file system used for storing code 

instances labeled "ourTypes." The MetaDataType class has associated with the application server, 

a method for populating "ourTypes" with a number of 40 In one embodiment, an additional template class defini- 

MetaDataType instances with stored metadata correspond- tion is generated that is a substantially empty subclass of the 

ing to different data types. "ourTypes" may be used as a first class (or "base class") definition (i.e., the template 

hbrary of information on data types, with methods for contains little or no code in the form of additional attributes 

accessing a specific MetaDataType instance by token value. or methods). In this case, the base class may be declared as 

The integer data structure, "myToken," stores the token 45 an abstract class. A developer can easily expand the capa- 

value assigned to a given MetaDataType instance. A string bilities of the respective base class by, for example, filling in 

data structure, "myTokenName," stores the character string the template with further attributes and methods as desired, 

representing the token name assigned to the given Meta- In step 603, a class building operation is performed to 

Dataiype instance. String structure "myJavaDeclaration" write the class definition for the client tier. As with step 602, 

specifies a character string for declaring, in the Java pro- 50 the class building operation uses the metadata to provide 

gramraing language, the data type described by the Meta- standard declarations, and to generate standard methods, 

DataType instance. The string structure, such as constructors, accessors, "new** methods and re flec- 

"myJavalnterfaceDeclaration," specifies a similar character tion methods. The class definition is typically written to a 

string for declaring the current data type if the data type is new file in a location within the file system used for storing 

an interface type. Other programming language declarations 55 code associated with a client application. Similar to the 

could be similarly represented, either alternatively or addi- application tier, an additional template class definition may 

tionally. String structures "myDatabaseDeclaration" and also be generated for the addition of further client specific 

"myDatabaseLength" are used in the construction of data- code. 

base tables. "myDatabaseDeclaration" specifies the charac- The class definitions for the application and client tiers 

ter string for the database data type, and "myDatabase- 60 share the same common interface, though the implementa- 

Lenglh" specifies the character string for the length of the tion of the interface may differ between the tiers. The 

data type in the database. interface is generated in step 604, and comprises, for 

MetaDataType 506 further comprises a reference, example, a list of import classes, a series of constant 

"myReferenceiype," to a MetaClass Instance, if the Meta- declarations (e.g., for token values assigned to the individual 

Dataiype instance corresponds to an object class described 65 class attributes), and a series of public method declarations, 

by a MetaClass. String structure "my Objectifier" specifies The interface is written to a location in the file system 

an objectifier for the MetaDataType instance, whereas string containing code files common to the application tier and the 
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client tier. The location of the interface file is included as an 
import in the class definitions generated in steps 602 and 
603. 

In step 605, if there are no further metaclasses, the process 
ends (step 607). However, if further metaclasses remain in 5 
the schema metadata, the next metaclass is obtained in step 
606, and the process returns to step 602 to generate class 
definition code from the next metaclass. 

FIG. 6B illustrates, in accordance with an embodiment of 
the invention, the process of the class building operation lO 
carried out in each of steps 602-604 of RG. 6A. For the 
following description, character strings for building the class 
definitions are depicted within quotes. Each string may be 
written to the respective class file using known print com- 
mands. Elements inside of "< >" are evaluated to fill the is 
character siring. As an example, an interface declaration and 
one embodiment for writing the interface declaration to a file 
are provided below. The print command uses a tabprintln( ) 
method of a print stream instance (ps). MetaClass access 
methods, getName( ) and getSuperClass( ), are used to 20 
obtain the interface and superclass names to provide evalu- 
ation of elements within "< >". 



25 



"public interface <classnaine>Def extends <superclass>Def* 
ps.tabprintlnCpublic interfiace" + getName( ) + "Def extends" + 
getSuperaass( ).getName( ) + "Def*); 



In one embodiment of the invention, generated methods 
for each class implement a *'try-catch" format or construct. 
The try-catch format appears as: 



(e.g., general code, methods, and constructor methods) and/ 
or a footer. In step 608 of FIG. 6B, the class header is 
written. The class header may comprise elements such as a 
header comment, a package declaration, a List of import 
declarations, class comments and a class declaration. In step 
609 of FIG. 6B, any constant declarations are written to the 
class definition file. To begin any of steps 609-613, a 
comment preface to the section (e.g., "//constants", etc.) may 
be written to the file to indicate what follows for easier 
reading of the class definition. 

To facilitate the use of reflection methods, integer 
attribute tokens may be assigned to each attribute. Access 
may then be made to each attribute using a general reflection 
method which includes an attribute token value as a param- 
eter. In one embodiment, the integer attribute tokens arc 
declared as constants in the common interface during step 
609. To account for all attributes inherited from 
superclasses, as well as those explicitly declared in the 
current class, a chain of classes is formed from the highest 
superclass in the hierarchy (i.e., the superclass that does not 
itself have a superclass specified, or the highest superclass 
that is not a general framework class) to the current class. 
Each attribute in the chain of classes is enumerated and 
assigned an attribute token that is declared as a constant. 

To assign attribute tokens, each attribute is given a token 
name, for example, by changing the attribute name to all 
capital letters (for constant naming conventions), and 
appending "ArTRIBUTE_TOKEN_" as a prefix. Each 



try { 

<"tTy" sequence of operations> 
} catch (Exception e) { 

<"catch" sequence of operations to be performed if an exception is caught> 

} 



In the above construct, the "try" sequence of operations 
(or a single operation) is executed. If one of the "try" 
sequence operations throws an exception, the "catch" 
sequence is executed. The try-catch format is advantageous 



attribute token is then assigned a different token value by 
incrementing the token value after each attribute token 
assignment. The list of constants may be written to the 
common interface in the following form: 



"public final static int AITRIBUTE_TOKEN_<ArrRIBUTENAMEl> - 0;" 
"public final static int ATrRIBUTE_TOKEN_<AITRIBUTENAME2> o i;" 
"public final static int ymTUBlJTE_TOKEN_<ATTRIBtJTENAME3> = 2;" 
etc. 



because it allows for problems to be identified at runtime 
through the issuance of exceptions, and it provides the 
opportunity for action to be taken to handle those exceptions 
thrown (e.g., display an appropriate error message to a user 
based on the type of exception thrown). 

In certain examples, case statements are described for 
directing executional flow based on the result of a test, such 
as the matching of a token value. Other forms of conditional 
statements, such as "If statements, may be similarly applied 
to control executional flow. 

In the embodiment described, a class file can include 
some or all of the foUowing: a class header, declarations 
(e.g., constant and variable declarations), program code 



55 In step 610 of FIG. 6B, the variable declarations are 
written based on the schema attribute metadata for the 
current class (e.g., the Vector of MetaAttribute structures). 
Each MetaAttribute is enumerated and its MetaDataType 
queried to determine the corresponding declaration (e.g., 

60 "myJavaDeclaration") for the given programming language. 
The variable name may be generated by, for example, adding 
the prefix "my" to the attribute name. An example of a 
variable declaration string for a single attribute is: 

"private <myJavaDecla ratio n>my<attributena me >;" 

65 

The variable declarations are generated in the same man- 
ner for the client and server base classes. In accordance with 
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an embodiment of the invention, variable declarations are 
not automatically generated for the common interface and 
the template classes. 

In step 611, general code is written to the class file in an 
automated fashion. For the client and server base classes, the 
general code comprises the character string elements of the 
Vector "my Code" for the current MetaClass. For the com- 
mon interface, the general code comprises the character 
string elements of the Vector "raylnterfaceCode" for the 
current MetaClass. Each string element is enumerated from 
the respective Vector, and written to the class file. In 
accordance with an embodiment of the invention, general 
code is not written to the template classes. 

In step 612, for the client and server base classes, a 
standard constructor is written to the class file. No construc- 
tor is necessary for the common interface or template 
classes. The automated constructor may include setting 
default values for the variables (attributes). The default 
values may be determined by enumerating the MetaAl- 
tributes of the MetaClass, and determining a default value 
from the MetaAttribute metadata and the corresponding 
MetaDataiype. An example of a constructor is as follows: 



"public <classname>( );" 

"{•• 

supcr( 

ottributenamo = <defaultvaluc>;" 
" <attribiJtciiamc> » cdcfaultvaluo;" 
etc. 



In step 613, the methods of the class file are written. No 
methods are written to the template classes because the 
methods are inherited from the base classes. Only the 
method declarations are written to the common interface. 
"New** method code is generated for those MetaAttributes 
whose "myOfferNewMethodFlag" is tme. Method code is 
generated for each of the methods specified in the Vector 
"myMethods" of MetaMethod elements. Accessor methods 
are generated for the class variables (i.e., for the attributes 
described by the MetaAttributes in the Vector 
"myAttributes"). Also, reflection methods are generated that 
allow for the attributes to be accessed by attribute token. 

In step 614, the footer is generated for the base classes, 
template classes and the common interface. In one 
embodiment, the footer comprises a close bracket symbol 
"}" that corresponds to the open bracket symbol generated 
in the class header. 
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class comments may comprise more class-specific 
comments, and may be written to the class file in the same 
manner as the header comment. 
The package declaration typically corresponds to the 

^ target directory for the class file which depends on whether 
the class definition is being generated for the client tier 
("client") or application tier ("server"), and whether the 
class definition is a base class, a template, or the shared 
interface. A case statement may be used to write the appro- 
priate package declaration based on the target, where the 
target is one of the following: client base class, client 
template class, server base class, server template class, or 
common interface. An example set of packages for class 

15 targets is given below: 



target package declaration 

20 client base class "package com.cmpny.group,app.client.core.base;" 
client template class "package coin.cmpny.group.app.clicnt.core;" 
server base class "package coin.cmpny.group.app.server,core.basc;" 
server template class "package coin.cmpny.group.app.5crvcrxore;" 
common interface "package com.cmpny.group.app.common.core;*' 

25 

The imports for the cunent class are determined by target. 
For example, for the client base class and the server base 
class, the path name for the package containing the interface 
is declared as an import. The path names for other elements 

30 of the three-tier framework that may be integrated with the 
generated class, such as change objects, may be declared as 
imports as well. For the client base class, the application 
server base class and the common interface, the string 
elements of the import Vector "my Imports" are enumerated 

35 to form import declarations that arc added to those already 
written to the class file. The template class files may forego 
the addition of imports. 

The class declaration is also target dependent. For the 
common interface, the interface name may be generated by, 
for example, appending a standard interface suffix, such as 
"Def," to the class name specified in the metadata. If there 
is a superclass specified in the metadata, an "extends" phrase 
may be added to the declaration which specifies a superclass 
interface name. The superclass interface name is generated 
by appending the interface suflBx to the superclass name. If 
there is no superclass, then the extends phrase is omitted. 
The declaration for the interface is as follows: 



superclass: "public interface <classname>Def extends <superclass>Def * 
no superclass: "public interface <cla8sname>Der' 



E^irther description is provided below with respect to the 
automated generation of code for the class header and 
method portions of the generated class files and common 
interface. 

Gass Header 

As stated above with reference to FIG. 6B, the class 
header comprises a header comment, a package declaration, 
a series of import declarations, class comments, and a class 
declaration. The header comment may include, for example, 
a standard copyright notice and/or the date of class genera- 
tion. The automated code generation writes the comment to 
the file (with appropriate comment line symbols, e.g., "/*" or 
"//"), for example, using known file print commands. The 



For the client and server base classes, the superclass is 
assumed to be "Object" if no superclass is specified. The 
class declaration for the client and server base classes is, for 
example: 



"public abstract class <classname> extends <superclass> 
implements cclassnatnoDef 



65 

For the client and server template classes, the superclass 
is the respective client or server base class with the path- 
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name (as given by the target packages) for the base class classes, a method body is generated in a try-catch format, for 
appended as a prefix to the class name. Thus, for the example, to obtain a new instance or to catch an exception 
template classes, the respective declarations are: in the event a new instance is not obtained. Typically, the 



client: "public class <cla88name> extends <clientBasePackage>.<classname>*' 

server: "public class <classaaine> extends <serverBa6e Package >.<clas8aanie>" 

"{" 



"New'' Methods 

"New" methods ("new<attributeName>," not "new 
<constructor>") are provided for those attribute types, such 
as Vectors, that contain objects as elements. The "new*' 
method provides a mechanism to obtain new instances of the 
object class forming each element of the Vector, and, in one 
embodiment, to initialize the mirror attribute of the new 
instance to refer to the class instance containing the Vector. 
The new class instances are obtained, for example, from the 
public store by invoking a method of the object representing 
the public store which returns a new instance for a specified 



new instance is obtained by calUng a method from a system 
component that handles the instantiation of the desired class 
within the context of the database. The following example of 
a "new" method body is provided in accordance with an 
embodiment of the invention. The method body incorporates 
the use of the factory class (e.g., from "my Factory Qass") 
for lookup of class token values, and assumes the base class 
is a subclass of a "StoredObject" class that supports the use 
of a public store (e.g., in the form of an object cache 
component) that performs instantiation. The example form 
of the method body is: 



15 



20 



" try {" 

" SchcmalnfoDcf schema » gctldcntity( ).gctClassIdcntLty( ).gctSchcina( );" 

Class IdenlityDef classID = schema. getClassForTbken(<:£actory ClassNa 
me>.CLASS_JOKEN_<de5iredClassName>);" 

<desiredClassName>Def newlnstance «• (<desiredaassName>Def) (ge 
tPubUcStore( ).newIiistanceForClassIdentity(classID));" 
" newlnstance. 5 ct<inirror Attribute Namc>(this);" 

return newlnstance;" 
*' } catch (exception e) {" 

gctPubIicStore( ).handleExceptioii(e);" 
*' return null;" 

" }" 



class ID. The public store object calls a factory method of a 
class factory to construct the new class instance. 

To generate a "new" method, the element 
"myCoUectionContent-Name" of a MetaAttribute's associ- 
ated MetaDataType is queried to determine the class name 45 
of the desired class instance to be created by the "neV 
method. The method declaration can then be generated as 
illustrated below, in terms of the desired class's correspond- 
ing interface (generally "<classname>Def *). In one 
embodiment, the method name is generated by appending 50 
"new"* as a prefix to the desired class name. 

"public <dcsircdQassNamc>Dcf ncw<dc5ircdCla58Namc>( )" 
(e.g., "public SampleObjectDef newSamp!eObject( )") 

For the common interface, a semicolon ";" is appended to 
the above method declaration. For the client and server base 



Specified Methods 

For the specified methods, i.e., those methods described 
by the MctaMcthod elements of the Vectors "my Methods" 
and "myPassedMethods," method declarations are added to 
the common interface. Those method declarations may 
include the comment strings specified in the respective 
string Vector "my Comments" of the respective MetaMelhod 
structure. The Java (or other programming language) dec- 
laration for the method's return data type is obtained from 
the data type metadata (e.g., from the MetaDataType struc- 
ture "myDalaType" of the MetaMethod), and the name of 
the method is obtained directly from the method metadata 
(e.g., "myName"). The parameter data types and names are 
obtained by enumerating the MetaParameters of the 
MetaMethod and querying the associated MetaDataType of 
each MctaParameter. If the string "myThrowsType" is not 
null, a "throws" phrase is added to the declaration, including 
the specified data type. Example declarations in accordance 
with an embodiment of the invention are provided below: 



(myThrow^Type—null): "public ■cretumDatal^o <inethodName>(<parameter 
DataTypo <:paranieterName>, <parameterData'iype> <paraineterNamc> <, ...>)" 
(myTliro\?reType!-null): "public <retumDataType> <methodName>(<parameter 
DataTypo cparametcrNamo, <parametcrDataTypc> <paranictcrNamc> <, ...>) 
throws <myThrowType>" 
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The client and server base classes receive the sanie 
general method declarations as shown above. Also, if the 
"myPassToAttribute" structure of the MetaMethod is null, 
the string elements of the Vector "myBody Parts" are enu- 
merated and printed to the class file to complete the body of ^ 
the respective method. If the "myPassToAttributc" is not 
null, meaning that the processing of the method is to be 
carried out by an identically named "passed" method of 
another class designated by "myPassToAttributc," the 
method body may be constructed, for example, as shown 
below, to make a further call to the other class and to return lO 
the result. The parameters of the new call include the same 
parameters as the current method with the addition of "this** 
to specify the current class as the caller, if "myPassThis- 
Flag" is true. For example: 

15 



(myPassThisRag): 
"{■■ 

" return get <attributcNa[nc >( ).<mcthod Name >(this, <paramcter>, 
<:parameter>, <etc.>);" 20 
"}" 

(ImyPassThisFlag): 
"{" 

" return gct<attributeNamc>( ).<incthodNamc>C<paramctcr>, 
<parainctcr>, <etc.>);" 

"}" 25 



Passed methods are generated in similar fashion to the 
specified methods described above. However, if 



method, as well as by the reflection methods. The protected 
"doSet" method is not included in the public interface of the 
class. 

The "Get" declaration is determined from the data type of 
the attribute and its corresponding Java (or other program- 
ming language) interface declaration. An example "Get" 
declaration is as follows: 



''pubIic<dataTypeJavaInter£aceDecIaration>gct<attrLbuteNaine>( )" 



The "Get" accessor method is designed to return the value 
of the variable targeted by the method, or its corresponding 
null value if the variable value cannot be obtained. For 
nonpersistent attributes, i.e., those attributes not saved in the 
database, the "Get" accessor may simply return the variable 
value using the phrase "return <variable name>" within the 
try -catch format. For persistent attributes, method calls may 
be embedded in the generated code to access the "public 
store" for the variable value. In one embodiment, the fol- 
lowing two "Get" method forms are used, the first being 
used if "rayMirrorCoUection Class" is null (i.e., the attribute 
is not a collection or set, such as a Vector of classes), and the 
second being used if "myMirrorCoUectionClass" is not null. 



(myMirrorCollcctionClasB = null): 

- tiy {" 

if(getNeeds'IbBeReadFromStore( )) readFromStoreC );" 
" return <variableName>;" 

** } catch (Exception c) }" 

* getPublicStore( ). handle E3H:eption(e);" 
** return <nullValueString>;" 

• }•• 

(myMirrorCoUectionClass != null): 

- try {" 

if (<:variableName> null) {" 

<variableName> o new RelationshipAwaieLiveSet(gctPublicStore( ), 

gctCla55lnfo( ).gctAttributcForName("<aUributcName>"), this);" 
y, 

return <variableName>" 
} catch (Exception e) {" 
" getPublicStore( ). handle Exception(e);" 

" return <nulI\^lueString>;" 

- }" 



"myPassThisFlag" is true, the parameter list in the method 
declaration includes an entry for the calling class, such as by 
adding the corresponding class type or interface type of the 55 
calling class (e.g., "<className>Def ') followed by "caller" 
as the standard parameter name for the calling class. 
Accessor Methods 

Accessor methods are automatically generated for each 
attribute described in a MetaClass instance. As with the 
other described methods, the common interface receives the 
method declarations for the "Get" and "Set" accessor 
methods, whereas the client and server base classes receive 
the complete methods, including declaration and body. A 65 
further protected accessor method, "doSet," is generated in 
one embodiment for use by certain instances of the "Set" 



In the above examples, for the datatype specified for the 
attribute, if "myPassByCopyRag" is true, the return phrase 
"return <variableName>" is replaced with the return phrase 
"return new <dala'IVpcJavaDeclaration> (<variableName>) 

to return a copy of the variable of the data type specified 
for the attribute. 

The "Set" accessor method is designed to write a value to 
the given variable (attribute), with the new value specified as 
a method parameter. In one embodiment, for collection 
attributes, such as Vectors of classes (i.e., those attributes 
whose "myMirrorCoUectionClass" is not null), no "Set" 
method is generated. The declaration of the "Set" method 
may be generated as follows: 
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"public void sel<attributeNaine>(<dataTypeJavaInterfaceDeclaration> 
<attributeName >)" 



The "Set" declaration alone is written to the common 
interface. The declaration and method body are written to 
the client and server base classes. In one embodiment, if the 
attribute is persistent and has a designated change object, the 
"Set" method initiates a transaction with the public store, 
obtains a change object with the appropriate attribute 
changes, performs the change using the change object, and 
ends the transaction with the public store. If the attribute is 
not persistent or does not have an assigned change object, 
the "Set" method calls the "doSet" method. "Set" method 
body examples arc provided below, with the first corre- 
sponding to a persistent attribute with a change object and 
the second corresponding to a nonpersistent attribute or one 
without an assigned change object. (Note: the attribute's 
"owning" class is the class containing the attribute.) 



if (<variableName> null)" 

<variab]eName> - new <dataTypeJavaDeclaration>( 
<variablcNa mo .copy (ottribute Name >) ;" 



Reflection Methods 

With respect to reflection methods, the common interface 
10 receives the declarations, and the client and server base 
classes receive the full methods. The reflection methods 
provide access to the attributes of a given class, including 
those inherited from superclasses, through the specification 
of an Attributelnfo structure that contains the attribute token 
15 of the desired attribute. A case statement is used, for 
example, to call either the "Get" or "doSet" accessor method 
for the desired attribute, as appropriate, based on which 
reflection method is invoked and the resolution of the 
attribute token. Examples of "Get" related reflection meth- 
ods in accordance with an embodiment of the invention are 
provided below. 



" try {" 

" gctPublicStorc( ).bcginTransactioD( );'* 

<changeObjectName> changeObject = new <changeObjectName>(this, 
<atlributc*8CKrabgaass'sInterfBocNamc>.ATTRIBUTE_TOKEN_<attributeName(all 
cap8)>, <attributeName>);" 

" gettHiblicStore( ).performChange (changeObject);" 

gctPublicStore( ).cndTYansaction( );" 
} catch (Exception e) {" 
" gctPubiicStorc( ).handlcExccplion(c);" 

„ }" 

do Se t <a ttributeName>( <a ttributeName>); ' ' 



Similar to the "Sef* methods, "doSet" methods are not 
generated for collection attributes, such as Vectors of classes 
(i.e., those attributes whose "myMirrorCoUectionClass" is 
not null). The "doSet" accessor methods are written to the 
client and server base classes, but, as stated previously, no 
declaration is written to the common interface for these 
protected methods. The "doSet" method is an internal 
method. Any transaction-based activities are handled by the 
caller. An example of a "doSef method is provided below 
in accordance with an embodiment of the invention. 



"protected void doSet<attributeName>(<dataTypeJavaInterfaoeDeclaration> 
<attributeName>)" 

" try 

if (getNeedsToBeReadFromStorc( )) readFromStore( );" 

<variableName> - <attributcName>;" 
" } catch (Exception e) {" 
" gctPublicStorc( ).handlcExccption(e);" 

-r 



If "myMirror Attribute" is not null and "myPassBy Copy- 
Flag" for the attribute's data type is true, the string 
"<variableName>«<attributeNamc>;" may be replaced by: 
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"public Object gctV^lucOrRcfcrcnccForAttributc(AttributcInfoDcf attribute)" 

" return get ValucFor Attribute (attribute, tiuc);" 

"public Object get\felueForAttribute(AttributeInfoDef attribute)" 
"{" 

return get\^lueForAttribute(attribute, false);" 

•*}•' 

"public Object get\felue For Attributc( Attribute InfoDef attribute, boolean idOnly)" 

" try {" 

Object returnV^ue = null;" 

switch(attributc.gcLAttributeTokcn( )) {" 

ocase 1>" 
" <case 2>" 

<ctc.>" 

)■■ 

" return rcturnV^luc;" 

) catch (exception e) {" 
" getPublicStore( ).handleException(e);" 

return null;" 

" }" 

2; 

For attributes that reference user classes, in one attributes that represent a collection (e.g., those attributes for 
embodiment, the case code "<case #>" is: which "myMirrorCIassCollection" is not null) are not 



" case <attributc'sOwningClass'sInterfaceName>.Al'l'KlBUTE_TDKEN 
_<attributeNamc(all caps)>:" 
if (idOnly) {" 

if (get<attributeName>( ) «*- null)" 
" return Vfelue - null;" 

" else" 

return "Vfelue = get<attributeName>( ).getldentity( );" 
} else {" 

return V^lue = get<attributeNarne>( );" 

" break;" 



For attributes that do not reference user classes, the case 40 included in the method. An example of a "Set" related 
code is: reflection method is provided below. 



case <attribute'50wningClass'sInteTfeccNamc>.ATTRIBUTE_TOKEN 
_<attributeName(all caps)>:" 

re turn Value - gct<attributcName>( ):" 
break; 



The "Set" related reflection method also uses a case 
statement to resolve attribute tokens for invocation of the 
appropriate accessor, in this case, the "doSet" method. Those 



"public void setV^luePorAttribute (Attribute I nf or Def attribute, Object value)" 

" try {" 

switch (attribute. getAttributeTbken( )) {" 
" <caBe 1>" 

<case 2>" 

<etc>" 

}" 

} catch (Exception e) {" 

getPublicStore( ).handleException(e);" 
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token value) and resolve a case statement based on the 



case <attribute'5<>vnmgCla5s'sIntcrfaceName>.ATTRIBUTE_T0KEN 
_<aUributeName(all caps)>:" 

" doSBt<attributcName>({<data'IVpeJavaDecIa ratio n>)value);" 

" break;" 



Thus, user class files and interfaces are automatically 
generated from the schema metadata to reduce redundant 
programming eflfort, and to provide automated integration of 
the user class files with other elements of the three-tier 
framework. 

Generation of Factory Classes 

As referred to previously with respect to step 403 of FIG. 
4, a factory object class is generated from the schema 
metadata. Classes that are part of the fi-amework (e.g., 
non-data objects) are imported into the factory class, and a 
standard constructor is generated. Qass tokens are generated 
as constant declarations by enumerating the MetaClass 
Vector "myCoreClasses" and individually assigning token 
names and token values. The token value is incremented 
between each new MetaClass. The token names may be 



specified token value to instantiate the desired class. 
Abstract classes need not be included in the factory method 
as abstract methods are not instantiated. If the factory class 
is generated for the server, the server template package is 
appended to the class name as a prefix for the class con- 
structor. For the factory class generated for the client, the 
client template package is similarly appended to the con- 
structor. In one embodiment of the invention, the factory 
20 method is configured to assign an "identit/' class instance to 
the newly instantiated data class (or "core" class). The 
identity instance is set with a class identity value and a serial 
number. Further, the public store is set for the new class 
instance before returning the class instance to the caller of 
the factory method. An example factory method is shown 
below: 



"public IdentifiableDef newInslanceForReference(ReferenceDcf rcf)" 
"throws Factory Exception" 

StoredObject newObject = null;" 
- try {" 

ClasslndentityDcf classid = null;" 
[dentity newldentity » null;" 

int classTokcn - rcf.gctClasstdcntity( ).gctClassTokcn( );" 
switch (class Tbkea) {*' 

case CLASS_„TOKEN_<className(aU caps)>:" 

ncwObject = new <(server/clic[it) template Pakcagoxclass 



Name>( );" 

<cla66 Name (all cap6)>); 



newldentity - new Identity( );" 

classId = getSchema( ).getClassFoiTol£en(CLASS_TOKEN„ 



newIdcntity.setCJassIdentity(classId);" 
" ncwIdentity.setSerialNumber(ref.getSerialNunibei^ ));" 

" ncwIdentity.8etIdentitySpace(rcf.getIdcntitySpace( ));" 

newObjed.setldentityijnewIdentity);" 
" break;" 

" <further case statements - one for each nou-abstract clas5>" 

" default:" 
" break;" 
}" 

" if (newObject — null) {** 

throw new FactoryException( );" 
} else {" 

newObjCct.sc iNecdaToBcRcad FromSto rc (false) ;" 
newObject.setPublicStore(getPublicStore( ));" 
" AttributelnfoDef aid - newObject.getCla8slnfo( ).getAttributeFor 

men(CoreObicctDcf.ATTRIBLrrE_TOKEN_HASBEENDELETED);" 

newObject.set\%ilueFcrAttribute(aid, new Boolean (false));" 

}" 

} catch (Schema Except ion e) { }" 
" return newObject;" 



assigned by adding a token prefix to each class name. For 
example, each token assignment may appear as a constant 
declaration as follows: 

"public final static int CLASS_TOKEN_<classNameCall caps)>« 
<token Number> ;" 

A factory method is generated that will receive a token 
value (or some other reference that is transformed into a 



The factory method above takes advantage of inherited 
methods and attributes of the new object instance to set 
public store information (e.g., provide a reference to the 
respective object cache component), as well as to set identity 
65 information on the new object instance. In one embodiment, 
each data object is a subclass of the framework "StoredOb- 
ject" class which is a subclass of a framework "AwareOb- 
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jecl" class. The SloredObject class provides the inherited 
methods for communicating with the public store. The 
AwareObject class implements an IdentifiableDef interface 
that provides methods for accessing class information such 
as class ID and serial number (object ID). The AwareObject 5 
class also provides methods for obtaining a list of class 
attributes and token values, and for accessing attribute 
information via token value, for example. 
Generation of Database Tables 

FIGS. 7A and 7B arc flow diagrams illustrating a process 
for generating database tables from schema metadata in 
accordance with an embodiment of the invention. The 
processes of FIGS. 7A and 7B may be implemented, for 
example, within schema class 907 of FIG. 9, and executed 
by an instance of the schema class at run time during initial 
start-up. 

The database tables are generated through a "create table" 
command that specifies the table name (or relationship) and 
the attributes that make up the table. The following descrip- 
tion refers to how to generate the a "create table" command 
from schema metadata. The embodiment described gener- 20 
ates a separate create table command, and therefore a 
separate database table, for each MetaClass instance. Other 
embodiments may, for example, generate one database table 
for multiple MetaClass instances, or muUiple database tables 
for a single MetaClass instance. An example of a create table 25 
command, in accordance with an embodiment of the 
invention, is provided below. 



CREATE TABLE <classNamc> ( 

oUribuleDa tabas e Declaratio n>, 
<attributeDataba3eDecla ratio ii>, 
<etc.> 



) 
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The create table commands may be included together in 
a script format and submitted in a "create database" com- 
mand set as shown below, for example. 



CREATE DATABASE <databa6eName> 

USE <databa5cNamc> 

CREATE TABLE <classNamel> ( 

<aUributcDa tabas cDcclaration>, 

<auributeDalabaseDeclaration>, 

<etc.> 

) 

CREATE TABLE <className2> ( 

<8UributcDa tabas cDcclaratLO a>, 
<aUributeDa tabaseDeclaratio n>, 
<etc.> 
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) 



<etc.> 



In FIG. 7 A, the process begins by obtaining the schema 
metadata in step 700. In step 701, the first MetaClass 55 
instance is obtained from the schema metadata, for example, 
using an enumeration process on the Vector of MetaClasses 
" my CoreCl asses." In step 702, a determination is made 
whether the current MetaClass is persistent, not abstract, and 
not an interface. If the MetaClass is abstract, is an interface 60 
or is not persistent, the process continues at step 710, 
bypassing generation of a "create table" command for the 
current MetaClass. If, however, the MetaClass is persistent, 
not abstract, and not an interface, the process continues at 
step 703, where the "create table" command is initiated, 65 
specifying the MetaClass class name as the relation or table 
name. 



In step 704, a determination is made whether the current 
MetaClass has a superclass specified. If there is no super- 
class specified (mySuperClass==null), the process continues 
at step 707 in which the MetaAttributes ("myAttributes") are 
obtained for the current MetaClass instance. In step 708, the 
database declarations for each attribute are added to the 
"create table" command. The process of step 708 is further 
described in FIG. 7B. 

If, at step 704, there is a superclass specified 
(mySuperQassIenuU), then the MetaClass instance for the 
specified superclass is obtained in step 705. In Step 706, the 
superclass MetaClass is processed as described in steps 
704-708 in a nested process ("A"). Nested process "A" can 
be executed recursively to process each superclass level in 
the class hierarchy. Step 706 ensures that attributes inherited 
from the superclass (and its superclass, and so on) are added 
to the "create table" command. After step 706, the process 
continues at step 707. 

In step 709, the "create table" command is closed (e.g., by 
appending a close parenthesis ")"), and the command is 
submitted, via the data store management component, to the 
database management system to configure the database. If 
more MetaClasses remain, as determined in step 710, the 
next MetaClass is obtained in step 711, and the process 
returns to step 702. If there are no more MetaClasses in step 
710, the process is completed. Submission of the finished 
"create table" commands may also be performed as a set, as 
described above for a "create database" command set. 

FIG. 7B further describes the process of adding attribute 
database declarations to the "create table" command. In 
accordance with an embodiment of the invention, the 
attribute database declaration has the following form: 



cattributcNamo -cattributcDatabascTypo <(<databa5c Length >)> 
<*'PRIMARY KEyr'NULL'TNOT NULL"> 



In Step 712 of FIG. 7B, the first MetaAttribute instance is 
obtained from the MetaAttributes for the current MetaClass, 
for example, through an enumeration of Vector "myAt- 
tributes." In step 713, a determination is made whether the 
current attribute is persistent (myPersistentRag==true). If 
the current attribute is not persistent, the process continues 
at step 724, bypassing the current MetaAttribute. If the 
current attribute is persistent in step 713, the attribute name 
is added to the "create table" command in step 714 to specify 
a column name in the table. 

In step 715, the MetaDataType instance of the current 
MetaAttribute instance is queried to determine the database 
type ("myDatabaseDeclaration") of the current attribute. In 
step 716, the database type is added to the "create table" 
command to specify the column type. In step 717, if the 
MetaDataType database length string "myDatabaseLength" 
is not "0," in step 718, the database length is added to the 
"create table" command in the form 
"(<myDatabaseLength>)". Step 718 proceeds to step 719. If 
"myDatabaseLength" is "0," the process proceeds from step 
717 to step 719. 

Steps 719-723 handle the setting of the database null 
declaration. In step 719, if "myPrimaryKeyFlag" is true, 
"PRIMARY KEY" is added to the "create table" command 
in step 720, and processing continues at step 724. If, in step 
719, "myPrimaryKeyFlag" is false, processing continues at 
step 721. In step 721, if "myNullFlag" is true, "NULL" is 
added to the "create table" command in step 722, and 
processing continues at step 724. If, in step 721, 
"myNuUFlag" is false, "NOT>aJLL" is added to the "create 
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table" command in step 723 before proceeding to step 724. 
In step 724, if any MetaAttribute instances remain for the 
current MetaClass instance, the next MetaAttribute instance 
is obtained in step 725, and the process returns to step 713. 
Otherwise, the process of entering attribute database decla- 
rations for the current "create table" command is complete. 

Thus, an integrated three-tier application framework with 
automated class and table generation has been described in 
conjunction with one or more specific embodiments. The 
invention is defined by the claims and their full scope of 
equivalents. 

We claim: 

1. A computer-implemented method comprising: 

obtaining a schema describing a data class; 

generating code for use in a multi-tier run-time environ- 
ment automatically from the schema, the multi-tier 
run-time environment including a client tier and an 
application tier, the generated code including a client 
class for the client tier and a server class for the 
application tier; 

bringing the generated code into a run-time environment 
having a set of framework components, the compo- 
nents including the client tier, the application tier, and 
a database tier; 

initiating a transaction in the client tier, the transaction 
including a change to be applied to a first data object, 
the first data object being an object of the client class 
cached by the client tier, the first data object represent- 
ing a datum; 

creating in the client tier a change object representing the 
change to be applied; 

communicating the change object from the client tier to 
the application tier; 

in the appHcation tier, applying the change represented by 
the change object thus communicated to a second data 
object, the second data object being an object of the 
server class cached by the application tier, the second 
data object representing said datum represented by the 
first data object; 
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in the application tier, converting the second data object 
with the change thus applied into a representation 
suitable for use by the database tier; 

communicating the representation from the application 
tier to the database tier; 

in a manner responsive to the representation thus 
communicated, changing a database entry in the data- 
base tier, the database entry including said datum 
) represented by the first and second data objects; 

notifying the application tier that the database entry has 
been changed; 

notifying the client tier that the datum represented by the 
second data object has been changed; 

in the client tier, changing a value in a field of the first data 
object so as to reflect the changed datum; 

in the client tier, closing the transaction; and 

making the first data object with the field thus updated 
^ available for further use in the run-time environment. 

2. The method of claim 1, wherein generating the code is 
accomplished using meta-data that is reflected in the gen- 
erated code. 

3. The method of claim 1, wherein creating the change 
* object in the client tier includes creating a change object 

described in terms of meta-data. 

4. The method of claim 1, wherein communicating the 
change object to the application tier includes serializing the 
change object using meta-data. 

^ 5. The method of claim 1, wherein applying the change to 
the second data object is accomplished using meta-data. 

6. The method of claim 1, wherein converting the second 
data object into a representation suitable for use by the 
database tier includes using meta-data to facilitate conver- 

^ sion of the second data object into said representation, 

7. The method of claim 1, wherein notifying the client tier 
that the datum represented by the second data object has 
been changed is accomplished using meta-data. 



07/28/2003, EAST Version: 1.04.0000 



